1. Field of the Invention
The invention relates to the field of printing systems and applications operable in accordance with document presentation architectures and in particular relates to an enhancement to document presentation architectures to provide for extendable meta-data to be formally associated with presentation files.
2. Statement of the Problem
In large enterprise document printing/presentation environments, various final form presentation datastream standards are used to provide for standardized, complete definition of the final form for printing or other presentation of a document file. As used herein, “final form” refers to the complete definition in the presentation document of all information to define the content of the document and the formatting for presentation to a user (e.g., printed, displayed, etc.). Some final form standards are referred to as a “datastream” in that they comprise a continuous stream of data defining a sequence of data representing a sequence of one or more sheet sides in a sequence of one or more documents.
The Advanced Function Presentation (“AFP”) architecture, such as that specified by IBM at www.ibm.com and entitled “Mixed Object Document Content Architecture” (“MO:DCA”—IBM document SC31-6802 which is hereby incorporated by reference), is exemplary of a final form presentation datastream and is often applied to high volume transaction processing printing and presentation environments. Although this patent application presents background information and solutions in the context of AFP architecture, similar issues arise in conjunction with other final form presentation datastream standards.
The AFP architecture is a broad specification applicable across an industry of transaction print processing/presentation applications and enterprises. The AFP architecture family of specifications generally specifies the format of files for presentation information including the information to be presented as well as commands and directives (e.g., AFP structured fields) that define intended manner of presentation for the information content within the AFP file. In general, information in an AFP file is referred to as “components” and the file itself may often be referred to as a “document”. In AFP terminology a “printfile” may contain one or more documents. For purposes of this presentation, the distinction is not important and thus “printfile” and “document” may be used interchangeably.
The AFP file architecture is designed to allow portability over a wide range of applications and systems. In particular, the AFP formatted files are capable of presentation on a variety of presentation devices having a wide variety of capabilities. In addition to presentation of final form presentation data, it is often useful to process the final form presentation data for other purposes besides presentation. For example, other application systems may process the final form presentation to translate/transform the information into other formats for other processing/presentation purposes. Or for example, other application systems may process the final form presentation data to extract information for other related processing. A system may wish to extract financial information from a final form presentation that represents billing information for customers or payment information for vendors, etc. Or, for example, a print operator may wish to request reprinting of a selected portion of the final form presentation data. Thus, an operator may use an application system to extract a portion of the presentation by reference to certain data—e.g., “reprint all pages that relate to customers in Colorado”. In customer support contexts, it is often required to access the actual statements which were sent to a customer, by recalling them from an archive and viewing them on-line in support of a customer phone call.
These and other such non-presentation related applications and systems may benefit from meta-data associated with the presentation file. Meta-data describes information regarding the presentation file other than the data therein to be presented. Attributes and other information regarding the presentation file may be encoded as meta-data and associated with the presentation file. Without meta-data to describe information for such non-presentation applications, the applications may be difficult or impossible, or may result in the exposure of sensitive client information.
However, presently known final form presentation datastreams, such as AFP, do not provide for standardized meta-data formats. Rather, at best, such meta-data may be provided ad-hoc by particular application systems such as by embedding free-form comment fields or objects in the AFP file. Such free-form ad-hoc annotations of a presentation file may provide limited usability for that particular application but cannot readily be utilized by any other non-presentation applications.
For example, the AFP architecture is also intended to permit translation into other formats for presentation and/or editing in a manner that attempts to assure a consistent format for presentation on a wide variety of presentation devices including, for example, displays and hardcopy printing systems. Thus the AFP file includes not only the actual data to be presented (e.g., text and graphical information) but also includes high level descriptions of requirements for formatting the information content to assure a consistent appearance on a wide variety of presentation devices. However, transforming this final form information into another format such as Adobe PDF format may benefit from meta-data that helps assure fidelity of the translation. This and other exemplary transformations require significant intelligence to avoid introducing errors in the various transformations and reverse transformations.
It is generally known in the industry to utilize meta-data to annotate a file with additional information beyond merely that which is required to render the information content of the file. For example, Hewlett Packard printing systems generally process a language referred to as PJL (print job language) useful for annotating the information content of a printable file to provide other information relevant to printing that job other than the mere information content to be rendered. Or, for example, Adobe PDF and Postscript languages specify a comment field that may be used for specifying free format information that may be useful to a particular application programmed to process such comments fields. Other than such specific applications, these comments fields and PJL may be ignored as irrelevant information—only the specific applications designed to process that information will perform any processing when such meta-data is encountered. All other applications not designed to process such information will typically skip the information when attempting to render or otherwise process the data in the print job file (i.e., the presentation file or document).
However, these exemplary known meta-data structures are insufficient to provide the richness of the meta-data required for the wide variety of non-presentation applications exemplified as above. For example, in the current AFP architecture, only ad-hoc un-architected methods or structures permit the addition of such meta-data to an AFP file. More importantly, there is no standard for structuring or organizing any such meta-data in AFP files to permit standardized processing of any included meta-data by any or all application programs compliant with the AFP architecture. Still further, there is no architected mechanism to associate the meta-data with objects of the presentation file. Rather, meta-data information, to the extent it is even utilized with AFP documents, tends to be created ad-hoc by a particular user and/or a particular application system and may therefore be useful only to that user or application. For example, the meta-data may be embedded as free-form commentary in an AFP “NOP” structured field or a “TLE” structured field. The information contained in a NOP structured field is not architected to any standards and the information content allowed in a TLE structured field is very limited.
It is evident from the above discussion that a need exists for an enhancement to the AFP architecture to permit standardized, architected utilization of meta-data for annotation of an AFP file.